The parameters in this section define and regulate the various actions that are available to units during a game.
Actions always start and complete (including all of their effects) within the same turn, and a unit can only do one at a time.
All actions are potentially available to all units, but the parameters can be set so as to deny any action type to any unit type. See the descriptions with each action type.
All action is limited by action points. Each unit gets a certain number at the beginning of each turn and expends them in the course of doing things. The usual expenditure is one point per action, but may be more, as defined for each type of action. A unit action must always consume at least one action point. Units can accumulate acp from turn to turn, and they can also reduce acp below zero.
UnitTypeProperty: acp-per-turn acp
This property is the basic allowance of action points that a unit gets each turn.
UnitTypeProperty: acp-min acp
This property specifies how far into "action debt" a unit can go during a turn before it is prevented entirely from acting. A unit with acp < 1 at the beginning of a turn cannot do anything at all.
UnitTypeProperty: acp-max acp
This property is
the maximum number of action points that a unit can save up.
The value -1 means that acp-max is equal to acp.
Extra acp is silently lost.
Defaults to -1.
UnitTypeProperty: free-acp acp
This property is
the value is the amount by which the action points for some
action can exceed the unit's currently available acp
and still allow that action.
Defaults to -1, which means enough free acp to
allow any action.
Note that a unit with an acp of 0 is completely unintelligent, about like a cow patty. Cow patties can be useful for blocking paths, hiding behind, and suchlike, and have the advantage that once they're in place, you don't have to manage them. Other units will have to pick them up and put them down, of course.
Table: material-to-act u m -> n
This table is a minimum amount of m needed for u to be able to act. The material is not consumed.
UnitTypeProperty: acp-damage-effect interpolation-list
This property is the effect of a unit's hp on its acp. The input value
is hp, while the output value is the acp to be added instead of
acp-per-turn. This list does not extrapolate. Defaults to
().
Table: acp-night-effect u t -> n
This table is the multiplier for unit's acp at night in each type of terrain.
Defaults to 100.
Table: acp-occupant-effect u1 u2 -> n
This table specifies the effect of occupants on the unit's acp. The
effect of each occupant is multiplied with the acp and divided by 100.
Defaults to 100.
UnitTypeProperty: acp-morale-effect interpolation-list
This property is the effect of morale on acp. The input value is
morale, and the result value is multiplied with acp, after it has been
modified for night effect, but before modification for temperature. The
result is divided by 100, so an effect < 100 reduces acp, an effect of
100 has no effect, and an effect > 100 increases acp. Defaults to
().
UnitTypeProperty: acp-per-turn-min acp
This property sets a lower limit on the effect of occupants, damage, and other modifiers on the acp to be added at the beginning of the turn.
UnitTypeProperty: acp-per-turn-max acp
This property set the upper limit on the effect of occupants and other
modifiers to the acp added at the beginning of the turn. Defaults to
-1, which indicate no limit.
GlobalVariable: use-side-priority t/f
This variable is true if the sides may only act one at a time;
otherwise, all sides and units may move simultaneously during a turn.
Defaults to false.
UnitTypeProperty: action-priority n
This property is the order in which units of this type will act. Higher numbers act earlier. If the difference between the priority of one type and another is greater than 100, then the earlier-acting units must finish acting before the later-acting units, otherwise a player can rearrange the actual acting order as desired.
Movement is the most common sort of action. This section covers movement over open terrain; the next section discusses interaction with transports.
The general theory of movement is that a unit not in a transport crosses its current cell terrain to the edge of the cell, crosses any border terrain, and then moves into the destination cell, OR it moves onto connection terrain, travels along connection terrain to the new cell, and maybe moves off the connection. If the unit starts in a transport, then the transport may ferry the unit over some of the intervening terrain, possibly as far as the unit's destination.
A unit's basic movement rate is defined by its speed, which is a ratio of the the unit's acp. A speed of 100% means that the unit can potentially enter as many cells as it has acp, while a speed of 20% means that the unit uses at least 5 acp to enter a cell.
Movement can only succeed if several conditions are met: the unit must be able to cross the border terrain, the destination must be inside the world (but see below), it must be able to exist on the terrain of the destination.
ActionType: move x y z
This is the action that a unit performs to go from its current
location to the cell at x,y at altitude z.
The destination must be within the move-range of the unit.
UnitTypeProperty: acp-to-move acp
This property is the number of acp a unit uses to do one move action.
Defaults to 1.
UnitTypeProperty: speed n
This property is the basic multiplier relating acp to the number
of cells that may be entered during a turn.
Defaults to 100.
UnitTypeProperty: speed-damage-effect interpolation-list
This property is the unit's speed if it is damaged.
The input value is the unit's hp, while the result value is the
unit speed to use instead of speed.
Defaults to ().
Table: speed-occupant-effect u1 u2 -> n%
This table is the percent change in the speed
of type u1 for each occupant of type u2.
If the basic speed of u1 is 0,
then the multiplication is performed
as if the speed were 1 instead.
Defaults to 100.
UnitTypeProperty: speed-wind-effect list
This property is a list that describes the effect of wind on the unit's speed. The effect is calculated using the wind in the cell that the unit is entering (not its current location?). The form of the list is
((<angle-list> <value>) ...), <value> = <number> | ((<force> <number>) (<force> <number>) ...)
where angle-list is a single number, list of number, or the
symbol all. For hex areas, the angles are 0 for downwind
(same direction), 1, 2, and 3 for directly upwind (opposite direction).
The force is the wind force in the cell, and number is the
multiplier for the speed, with 100 having no effect, numbers
less than 100 decreasing the unit's speed, and numbers greater
than 100 increasing it.
Defaults to ().
UnitTypeProperty: speed-min mp
This property is the worst-case speed of a unit.
UnitTypeProperty: speed-max mp
This property is the upper bound on a unit's movement in one turn. (?)
UnitTypeProperty: move-range n
This property is the maximum distance allowed to the destination cell.
Defaults to 1.
The product of a unit's acp and its speed is its available movement points. Any move between cells will cost at least one movement point. Some mp costs may be negative, but the total mp for a move will always be at least 1.
Table: mp-to-leave-terrain u t -> mp
This table is the mp cost to leave a cell of type t. If t is a border type, this cost is never used. If t is a connection type, this cost is the cost of leaving the connection terrain for the open terrain of the cell. If t is a coating type, then this value adds to the cost of leaving the cell.
Table: mp-to-enter-terrain u t -> mp
This table is the mp cost to enter a cell of type t.
If t is a border type, this cost is the
cost of crossing the border.
If t is a connection type, this cost is the cost of entering the
connection terrain from the open terrain of the cell.
If t is a coating type, then this value adds to the cost
of entering the cell.
Defaults to 1.
Table: mp-to-traverse u t -> mp
This table gives the cost to travel along a connection or border of the given type. (note that the other costs are irrelevant if unit starts and ends its movement on the connection).
A special type of move known as a border slide can occur when the endpoints of a border touch on the start and destination cells. Sliding works like normal movement that happens to end up on a nonadjacent cell. Same rules for permissibility apply. If the value is negative, then border sliding is not possible.
Defaults to 1.
If both enter/traverse/leave and enter/leave movement is possible, then Xconq will automatically choose the cheapest alternative.
Each unit type has a range of altitudes within which it normally operates.
Table: altitude-min u t -> n
This table is the minimum altitude possible for each type of unit on each type of terrain.
Table: altitude-max u t -> n
This table is the maximum altitude possible for each type of unit on each type of terrain.
UnitTypeProperty: mp-to-leave-world mp
This property is an additional move cost to leave the world entirely.
To leave, the unit must be within its move-range of an edge, and
have sufficient mp to move into the terrain in the edge cell designated
as the destination of the move. If the value is -1, then the
unit may never leave. Defaults to -1.
UnitTypeProperty: free-mp mp
This property is the amount by which the move points can "go into the red" and still allow one more move.
ZOC is exerted only over units out in the open, has no effect on
occupants, unless they leave their transport. Occupants can themselves
exert a ZOC, if occupant-can-fight is true. ZOC applies to all
units on a hostile side.
Table: zoc-range u1 u2 -> dist
This table is the maximum distance at which type u1 exerts a ZOC
over type u2. A value of 0 means that the unit controls
only its own cell, and a value of -1 means that the unit does not
exert a ZOC at all. Defaults to 0.
Table: zoc-into-terrain u t -> t/f
This table is true if the unit exerts its ZOC into terrain
t. Defaults to true.
Table: zoc-from-terrain-effect u t -> n
Table: mp-to-enter-zoc u1 u2 -> mp
This table specifies extra movement points needed to enter the ZOC.
-1 prevents entry entirely. Defaults to -1.
Table: mp-to-leave-zoc u1 u2 -> mp
This table specifies extra movement points needed to leave the ZOC.
-1 prevents departure entirely.
Table: mp-to-traverse-zoc u1 u2 -> mp
This table specifies extra movement points needed to move within the
ZOC. -1 prevents traversing entirely.
If multiple units exert a ZOC into the same cell, then the mp cost is the maximum of the different ZOC costs.
Table: mp-to-enter-own u1 u2 -> mp
This table specifies extra movement points needed to enter a unit's own
cell, irrespective of ZOC. -1 prevents entry entirely. Defaults
to -1.
Units may use up some of their materials when they move. Consumption happens after the move action, and only for successful moves.
Table: material-to-move u m -> n
This table is the amount of each material that a unit of type u must have in order to be able to move.
Table: consumption-per-move u m -> n
This table is the amount of each material used by a unit to do one move action. The amount taken is independent of terrain. If the unit has less than the required amount of any of these materials, it is immobilized until it gets more (this is tested before each move action; note that this does not affect any other action, including entering and leaving transports).
Table: control-range u t -> dist
This table is the distance out to which a unit's entry into a cell
changes control of the surrounding terrain. A distance of 0 means that
the unit only changes control for its own cell, while a distance of -1
means that the unit does not affect control. Defaults to -1.
Table: keep-control-range u t -> dist
This table is the distance out to which a unit's presence maintains
control of the surrounding terrain. Defaults to -1.
Units can be inside other units, and have units inside them, in a tree-like fashion. There is no limit on the depth of the tree, but most occupant-transport relationships have other limits.
ActionType: enter unit
This is the action to enter the given unit.
UnitTypeProperty: acp-to-enter-unit acp
This property is the number of acp a unit uses to do one entry action.
Defaults to 1.
Table: can-enter-independent u1 u2 -> t/f
This table is true if a unit u1 can enter an independent unit u2.
Defaults to false.
Entering and leaving incur mp costs as does movment, but units with a speed of 0 may enter and leave transports.
Table: mp-to-enter-unit u1 u2 -> n
This table is the extra movement points required for u1 to enter the transport u2, and vice versa (i.e. how much of transport's time is consumed by the process).
Table: mp-to-leave-unit u1 u2 -> n
Note that these mp consumptions need not be symmetrical between occupant and transport, so for instance a passenger can use 2 of its mp to get on a transport, while costing the transport only one of its mp.
Table: ferry-on-entry u1 u2 -> ferry-type
Table: ferry-on-departure u1 u2 -> ferry-type
This table specifies how much intervening terrain the unit u2
entering or leaving transport u1
will have to cross on its own (and thus incur the terrain's mp costs and
limitations).
Defaults to over-border.
GlobalConstant: over-nothing
This constant indicates no ferrying, occupant must pay all costs to go to destination cell.
GlobalConstant: over-own
This constant indicates that the transport ferries over terrain of its own cell.
GlobalConstant: over-border
This constant indicates that the transport ferries over any border terrain also.
GlobalConstant: over-all
This constant indicates that the transport ferries to destination cell, effectively putting occupant on middle of cell, on connection terrain if necessary.
Research is an action performed by a unit with the sole effect of increasing its side's tech level. Research cannot be performed by independent units.
ActionType: research u
This is the action of researching the unit type u. If the action is valid, then the tech level of the side will increase. Unit types with any tech crossover will also have their tech levels adjusted.
UnitTypeProperty: acp-to-research acp
This property is the number of action points used up by one research action.
Defaults to 0, which disallows research.
Table: tech-per-research u1 u2 -> .01n
This table is the gain in tech level resulting from a research action, expressed as 1/100 of a level. This value is stochastic.
UnitTypeProperty: tech-per-turn-max tl
This property is a ceiling on the total gain of tech level possible in one turn
for each side and this unit type.
Defaults to 9999.
Table: material-to-research u m -> n
This table is the amount of each material a unit must have in order to do any research.
There are several stages in the construction of a unit: tooling up, creation, and completion. Tooling up is where the building unit prepares to build, creation is the step where the new unit comes into existence, and completion is where the new unit is brought up to being operational.
For the player, this is mostly automatic; if tooling must be done first, a user command to build will generate the appropriate actions.
Once the technology has been achieved, a unit that intends to construct other units may need to tool up. This is expressed as tool points or tp. Tool points start at zero, can be increased by tooling actions, and may gradually decline (representing wear and tear on the equipment).
ActionType: toolup u
This is the action of tooling up to build a unit of type u.
The result is an increase in the tp for the acting unit.
UnitTypeProperty: acp-to-toolup acp
This property gives the number of acp needed to do a toolup action.
Defaults to 0, which disallows tooling up.
Table: tp-per-toolup u1 u2 -> tp
This table is the number of tp gained by one tooling action.
Table: tp-to-build u1 u2 -> tp
This table is the number of toolup points needed before a unit of type u1 can create or build a unit of type u2.
Table: tp-max u1 u2 -> tp
This table is the maximum possible tooling.
Table: tp-attrition u1 u2 -> tp
This table is the number of .01 tool points automatically lost at the end of each turn.
Table: tp-crossover u1 u2 -> n%
This table is the number of tool points for u2 that is
guaranteed to exist, expressed as a percentage of the tool
points for u1.
For instance, if tp-crossover is 80,
and a unit's tool points for u1
is 10 out of a max of 20, and the max for u2 is also 20,
then the unit will have tool points for u2 at least 8.
When a constructing unit is tooled up, the build action creates a unit
immediately and puts it in its designated location, whether inside the
unit doing the building or somewhere nearby. This new unit, however, is
incomplete, representing the keel of the ship or the surveyor's
lines for an airstrip. Incomplete units are thus basically skeletons,
with some unit characteristics, but unable to move or act in any way.
They also cannot have any occupants, unless the occupants are of a type
that can complete the unit. Those occupants do not derive any protection
or other advantages from occupying the incomplete unit, and they are not
affected by the occupant-can-build limitation.
ActionType: create-in u unit
This action creates a new unit of type u occupying the given unit unit. The unit unit must have room for the new unit.
ActionType: create-at u x y z
This action creates a new unit of type u in the open at x,y,z. The cell must have room for this new unit.
Table: acp-to-create u1 u2 -> acp
This table is the acp used by a unit of type u1 to create a a unit of type u2. If zero, then u1 cannot create a u2.
Table: create-range u1 u2 -> dist
This table is the maximum distance at which a unit of type u1 can create a unit of type u2.
Table: cp-on-creation u1 u2 -> cp
This table is the completeness of a unit of type u2 when
created by a unit of type u1.
Defaults to 1.
Table: material-to-create u m -> n
This table is the total amount of a material type m needed to create a unit of type u.
Table: consumption-on-creation u m -> n
This table is the amount of a material type m consumed to create a unit of type u.
Table: supply-on-creation u m -> n
This table is the amount of supply of each material type m to give a newly created unit of type u. This supply is newly generated, does not come from anywhere else. (Note that players could cheat by creating units, taking their supply, and never completing them.)
Table: morale-on-creation u1 u2 -> n
This table is the ratio of morale of a unit of type u2 to
the morale of its creator u1, with 100 meaning that the
new unit has the same morale as its creator.
Defaults to 100.
Table: opinions-on-creation u1 u2 -> n
This table is the ratio of the opinions of a unit of type u2 to
the opinions of its creator u1, with 100 meaning that the
new unit has the same opinions as its creator.
Defaults to 100.
Once an incomplete unit has been created, other units can help to complete it.
ActionType: build unit
This action adds to the completeness of unit. If the unit becomes complete, it will be given its initial supply, acp, name, etc.
Table: acp-to-build u1 u2 -> acp
This table is the acp used up by one build action by a unit of type u1 when buiding a unit of type u2.
Table: cp-per-build u1 u2 -> cp
This table is the amount of completeness of a unit of type u2
added by each completion action performed by a unit of type u1.
If 0, then u1 cannot contribute to completing u2.
Defaults to 1.
Table: material-to-build u1 m -> n
This table is the amount of each material type m that u1 must have in order to build anything at all.
Table: consumption-per-build u2 m -> n
This table is the total amount of each material type m consumed by the completion of a unit of type u2. To calculate the consumption of a single build action, this amount is divided by u2's cp and multiplied by the number of cp added by the action. Fractions round up when the unit's cp is low, so that the full consumption happens.
Table: build-range u1 u2 -> dist
This table is the maximum distance allowed between a unit of type u1
and the incomplete unit of type u2 it is working on.
Defaults to 0, which requires the two units to be in
the same cell.
At a given point, incomplete units can make progress towards completion on their own. This is automatic because incomplete units are unable to act, and occurs at a constant specified rate. Automatic completion always occurs, even if other units are doing build actions at the same time. The incomplete unit must have any necessary supplies.
UnitTypeProperty: cp-to-self-build cp
This property is the minimum completeness of the unit necessary before it can work on itself.
UnitTypeProperty: cp-per-self-build cp
This property is the completeness added each turn when a unit works on itself.
Table: supply-on-completion u m -> n
This table is the minimum amount of supply of each material type m guaranteed to a newly completed unit of type u. If not already available to the unit, it will be newly generated.
UnitTypeProperty: cp-attrition .01n%
This property is the chance that an incomplete unit will lose cp. If the unit loses all of its cp, it vanishes.
Units can restore their own and each other's hp by doing repairs.
Repair requires a repair action.
The action points for this action
are taken from both the unit being repaired and
the repairer (using the same table acp-to-repair).
When a unit repairs itself, the action cost is counted once only.
ActionType: repair unit
This is the action of repairing the given unit.
Table: acp-to-repair u1 u2 -> acp
This table is the number of action points used up
by a unit of type u1
doing one repair action on a unit of type u2.
Defaults to 0, which disallows the action.
Table: hp-per-repair u1 u2 -> .01hp
This table is the hundredths of a hp that a single repair action by a unit of type u1 restores to a unit of type u2. The fraction of this over 100 is added to hp directly, while the < 100 fraction is added probabilistically. (For example, a value of 160 means that 1 hp will be added for each action, and there is a 60% chance that a second hp will be added also.)
Materials may be needed and/or consumed during repair. The materials will be taken from the unit being repaired, then from the repairer.
Table: material-to-repair u m -> .01n
This table is the amount of each material type m needed
for one repair action.
As with hp-per-repair,
the < 100 part is average, and > 100 is guaranteed.
Table: consumption-per-repair u m -> .01n
This table is the amount of each material type m used up by a repair action.
The repairing unit must also not be too damaged itself to do repairs.
Table: hp-to-repair u1 u2 -> hp
This table is the minimum hp level required of a unit of type u1
to repair a unit of type u2.
If less, then u1 is too damaged to do any repairing.
Defaults to 1, which allows repair always.
The following are not really part of the repair action definition, since they occur automatically, but they share many of the tables above.
Table: auto-repair u1 u2 -> .01hp
This table is the amount of repair (in 1/100 hp) that u1 will do
on any unit of type u2 within range (auto-repair-range).
As with hp-per-repair,
the < 1.00 part is average, and > 1.00 is guaranteed.
Material requirements and usage are as for repair actions.
Defaults to 0, which disallows auto-repair.
Table: auto-repair-range u1 u2 -> dist
This table is the distance out to which u1 will auto-repair
any damaged u2. A value of 0 requires the two units
to be in the same cell, while a value of -1 means that
u2 must be either an occupant or transport of u1.
Units can produce materials by explicit action.
ActionType: produce m
This action results in a quantity of material m coming into existence.
Table: acp-to-produce u m -> acp
This table is the acp used up by one produce action.
Table: material-per-production u m -> n
This table is the amount of material produced by u when acting to produce type m.
Table: material-to-produce u m -> n
This table is the amount of each material a unit must have in order to produce any material.
Although most movement of materials between units happens automatically (see backdrop economy description), players can also do it explicitly. Players can both take materials from other units, and give a unit's materials to others.
ActionType: transfer unit m n
This is the action of transferring supply to the given unit unit. The desired amount is n; if m is a valid material type, then only that type will be transferred, otherwise the action will transfer all types of materials possible. The actual transfer amounts may be less than n.
Table: acp-to-unload u1 m -> acp
Table: acp-to-load u1 m -> acp
These tables are the number of action points used up by one material
transfer action from u1 to u2. The amount is independent of
the material type being transferred. If either value is 0, then
the material cannot be transferred.
Table: unload-max u1 m -> n
These two tables determine how much of material m can be
transferred out of a unit of type u1 and into one of type u2
in one transfer action. The actual quantity transferred by the action
is the minimum of these two values. A value of 0 disallows
manual transfer. Both default to -1, which allows any amount to
be transferred.
ActionType: change-side side
This is the action of changing the unit's side to side. The side can be any allowable side, and the unit may be any unit controlled by the actor's side.
UnitTypeProperty: acp-to-change-side acp
If the value of this property is greater than 0, then this type of unit can be ordered to change to another given side. If the unit is not a type that can act, then the side change happens immediately, instead of as an action, and no acp cost is incurred. The type must also be allowed to be on the new side.
Disbanding is the voluntary and controlled destruction of a unit,
performed by the unit itself or another unit.
A disbanded unit always vanishes, rather than changing to its
wrecked-type.
ActionType: disband unit
This is the action of removing hp from unit. The unit will vanish if all its hit points are gone.
UnitTypeProperty: acp-to-disband acp
If the value of this property is greater than 0, then this is the acp that will be used up to do one disband action. If the unit is not a type that can act, then the disband happens immediately, instead of as an action, and no acp cost is incurred.
UnitTypeProperty: hp-per-disband hp
This table is the number of hp lost in a disband action.
Defaults to 0, which disallows disbanding.
A disbanded unit can be scavenged for materials.
Table: supply-per-disband u m -> n%
This table is the percentage of the unit's supply that is recovered
from a single disband action.
If the value is zero, then the unit's supply will not be
recovered by the disbanding process, and be lost permanently.
If any supply remains when the unit's hp is 0, then that
supply will be lost also.
Defaults to 100, which means that the entire supply
will be recovered on the first disband action.
Note that if an essential supply is 100% recovered before the unit is completely disbanded, then it may die from starvation first. A partly-disbanded unit may still acquire supply from nearby units, via the backdrop economy.
Table: recycleable-material u m -> n
This table is the quantity of each type of material that becomes available when a unit is completely disbanded. The materials go to transports, occupants, and nearby units, in that order. Any materials exceeding capacities of these units will be discarded. These materials become available only when the unit vanishes.
Units of variable size can transfer parts of themselves to other units, or create a new unit.
ActionType: transfer-part n unit
This action moves n parts of the actee to unit, or creates a new unit if unit is omitted. If n is negative, this takes from unit instead. If the action takes all the parts of any involved unit, then it vanishes.
UnitTypeProperty: acp-to-transfer-part acp
This property is the number of acp used up by the unit when doing a part transfer action. If 0, then part transfer is not allowed.
Units may change their type.
ActionType: change-type u
This action changes the type of the actee unit to the type u. Upon changing, the relationships of the unit with the world and with other units will be recalculated; occupants that can no longer stay in the unit will be ejected or disappear. The unit itself may vanish or wreck, if it is in the open on a terrain type that will cause units of the new type to vanish or wreck.
Table: acp-to-change-type u1 u2 -> acp
This table is the number of acp needed to change a unit of type u1 into a unit of type u2. If the value is 0, then the change is never possible.
Table: material-to-change-type u m -> n
This is the amount of each material type m required for a unit to change into a unit of type u.
Xconq combat is somewhat abstract; the attacking player decides what sort of attack to mount and perhaps when to retreat, but all else happens automatically.
The attacker/defender distinction applies only to a single action.
ActionType: attack unit commit
This action is a direct attack on the given unit, at a commitment level of commit. The unit must be known to the attacking unit's side.
ActionType: overrun x y z commit
This action is a combined attack/capture/move action. The basic theory
of an overrun is that the actor will attack, capture, or co-occupy the
cell at x,y, elevation z, with a commitment of
commit. The exact effects depend on the types and sides of units
in the destination.
[The commitment levels are currently ignored.]
Table: acp-to-attack u1 u2 -> acp
This table is the number of action points used up by a unit u1
when attacking a unit of type u2. If the value is 0, attack is
not allowed. Defaults to 1.
Table: acp-to-defend u1 u2 -> acp
This table is the number of action points used up by a unit u1
when defending against an attack by a unit of type u2. If the
value is 0, attack is not allowed. Defaults to 1.
Table: attack-range-min u1 u2 -> dist
This table is the minimum distance at which a unit can attack another. A value of 0 means that units in the same cell can fight.
Table: attack-range u1 u2 -> dist
This table is the maximum distance at which a unit can attack another.
A value of 1 means that units in adjacent cells may fight, while a value
of 0 means that only units in the same cell may fight. Defaults to
1.
One round of combat consists of an attack, a reaction, and a calculation of effects.
The defender's reaction is completely automatic, and occurs as part of the combat round. The defender's side does not get a chance to decide what to do until the next round, although doctrine may constrain the set of reactions.
Table: surrender-chance-per-attack u1 u2 -> n%
This table is the chance that u2 will surrender to u1 immediately upon being attacked.
Table: withdraw-chance-per-attack u1 u2 -> n%
This table is the chance that u2 will retreat from u1 immediately upon being attacked.
Table: acp-for-retreat u1 u2 -> acp
This table is the extra acp that u2 can get in order to make a withdrawal possible.
Table: counterattack u1 u2 -> n
This table is the strength of a defender's reaction to an attack. If 0,
the defender does not counterattack; if 100, the defender counterattacks
at the same level as if it attacked normally. Defaults to 100.
In an overrun action, if all the defending units are destroyed, the attacker has sufficient acp and mp, and the destination is safe to enter, then the attacker can move into the defenders' cell.
Firing is a kind of attack that can take place at a distance, involves no commitment or counterattack, and for which the type of ammo may be selected.
ActionType: fire-at unit m
This is the action of firing at a given unit. If m is a valid material type, then that type will be used as ammo, otherwise all available types will be used together.
ActionType: fire-into x y z m
This is the action of firing into the cell at x,y. If z is a valid altitude, then the fire will be concentrated on units at that elevation. If m is a valid material type, then that type will be used as ammo, otherwise all available types will be used together.
UnitTypeProperty: acp-to-fire acp
If this property is greater than 0, this type may attack by firing.
Table: acp-to-be-fired-on u1 u2 -> acp
This table is the acp lost when a unit is being fired upon. Defaults to
1.
UnitTypeProperty: range dist
This property is the maximum distance in cells to which a unit can fire.
Defaults to 1.
UnitTypeProperty: range-min dist
This property is the minimum distance in cells to which a unit can fire.
UnitTypeProperty: fire-angle-max n%
This property is the highest angle at which a unit may fire, expressed
as a percentage of 45 degrees. The default of 0 means that the
unit's fire has a flat trajectory and that the target must be on an
unobstructed straight line from the firing unit. For values greater
than 0, this angle is used to calculate whether the parabolic trajectory
clears all intervening terrain.
Table: weapon-height u t -> elev
This property is the effective height of a unit's weapons when in the given terrain.
Both attack and fire combat calculate hits and damage in a similar way, although they may use different tables.
Table: hit-chance u1 u2 -> n%
This table is the basic chance that a unit of type u1 will
actually hit a unit of type u2. If the hit chance is 0,
then the unit may never attack a unit of that type.
Table: fire-hit-chance u1 u2 -> n%
This table is the basic chance that fire from a unit of type u1
will actually hit a unit of type u2. If the hit chance is
0, then the unit may never fire at a unit of that type. If the
value is -1, then the value of this is the same as the value of
hit-chance. Defaults to -1.
Table: attack-terrain-effect u1 t -> n%
Table: defend-terrain-effect u2 t -> n%
Table: fire-attack-terrain-effect u1 t -> n%
Table: fire-defend-terrain-effect u2 t -> n%
These tables specify the effect of attacker's and defender's respective
terrains on hit-chance or fire-hit-chance. These chances
are multiplied with the basic hit chance. Default to 100.
Table: hit-cxp-effect u1 u2 -> n
This table is the effect of combat experience on hit chance. Its value
is interpolated according to actual experience (n is the effect
when u1 is at its maximum possible experience), then multiplied
with the hit chance. Defaults to 100.
The effectiveness of fire may be less at long ranges. If the range to
the target is greater than hit-falloff-range, the chance of
hitting it will be reduced by the interpolation between the short-range
chance and that chance multiplied by the value of
hit-at-max-range-effect. For example, if a unit's range is 4,
its hit falloff range is 1, the basic hit chance is 60%, and the max
range effect is 50%, then its hit chance at range 2 is 50%, at range 3
is 40%, and at range 4 is 30%.
Table: hit-falloff-range u1 u2 -> n
This table is the maximum range at which the effectiveness of combat is
not affected by distance. Defaults to 1.
Table: hit-at-max-range-effect u1 u2 -> n%
This is the multiplier for the effectiveness of firing at the maximum
range possible. Defaults to 100.
Table: damage u1 u2 -> hp
This table is the basic amount of damage caused by a successful attack.
The value is a dice spec. Defaults to 1.
Table: fire-damage u1 u2 -> hp
This table is the basic amount of damage caused by a successful firing.
The value is a dice spec. If the value is -1, then it is the
same as damage. Defaults to -1.
Table: tp-damage u1 u2 -> tp
This table is the amount of damage to a unit's tooling caused by a successful attack. The value is a dice spec.
Table: damage-cxp-effect u1 u2 -> n
This table is the effect of combat experience on damage. Its value is
interpolated according to actual experience (so that n is the
effect when u1 is at its maximum experience), then multiplied with
both the dice size and the addend of the damage spec. Defaults to
100.
Table: hp-min u1 u2 -> hp
This table is the lowest hp possible for u1 from attacks by u2. Further attacks by u2 are still valid, but can do no further damage.
You can set a unit to use a material as ammo.
Table: consumption-per-attack u1 m -> n
Table: consumption-per-fire u1 m -> n
These tables specify material consumption in combat. For each material
m, the min of these two values is the amount of u1's supply used
up in an attack on u2. Both default to 0.
Table: material-to-attack u m -> n
This table is a minimum of each material type m that a unit must have to engage in direct attack or to defend against it. This minimum is not necessarily used up in combat, it just needs to be present.
Table: material-to-fire u m -> n
This table is a minimum of each material type m that a unit must have to fire. This minimum is not necessarily used up, it just needs to be present.
Transports can protect their occupants, and vice versa.
Table: protection u1 u2 -> n%
This table gives the effect of occupants of type u1 on the chance
of another unit's attack hitting their transport u2, as well as
the effect of the transport u1 on the chance that occupants of
type u2 will be hit. This is a multiplier, where 100 has no
protection, values less than 100 decrease hit chance, and values greater
than 100 increase it. Each occupant will be taken into account when
computing transport's protection. Defaults to 100.
A transport's destruction may leave occupants stranded on hex, will do some sort of auto-escape or die if terrain is hostile.
Units stacked together can protect each other.
Table: stack-protection u1 u2 -> n%
This table is the effect of units of type u1 on attacks on units
of type u2 that are in the same cell. The effect is similar to
that described for the protection table. Defaults to 100.
Several other side-effects of combat may also be defined.
Units can retreat if they are about to be damaged; the retreat attempt is automatic, and will be in a valid direction that is away from the attacker. The retreat attempt will fail if there is no direction that the unit may move, or if has insufficient materials, acp, etc to do the movement. If the attempt is successful, then the unit will not be damaged; otherwise it must take the hit.
Table: retreat-chance u1 u2 -> n%
This table is the chance that u2 will attempt to retreat if it is hit by u1.
Units may gain experience as a result of combat.
Table: cxp-per-combat u1 u2 -> cxp
This table is the number of combat experience points gained by u1 by surviving a combat round with u2. Both attackers and defenders gain experience equally.
Unit morale may change as a result of combat, either positively or negatively.
Table: morale-hit u1 u2 -> .01n
This table is the 100ths of morale gained as the result of a unit of type u1 successfully hitting a unit of type u2. The part of the number > 100 is gained always, the part modulo 100 is the probability of gaining 1.
Table: morale-hit-by u1 u2 -> .01n
This table is the 100ths of morale lost as the result of a unit of type u1 being hit by a unit of type u2.
A unit may attempt to capture another unit directly. If successful, the captured unit's side changes to that of the capturing unit.
ActionType: capture unit
This is the action of capturing the given unit.
Table: acp-to-capture u1 u2 -> acp
This table is the number of acp used up by a capture action.
Defaults to 0, which disallows capture.
Table: bridge u1 u2 -> t/f
This table is true if a unit of type u1 can be captured by a unit
of type u2 even if u1 is on a type of terrain impassable to
the capturing unit. Defaults to false.
Table: capture-chance u1 u2 -> n%
This table is the basic chance for u1 to capture u2.
Table: independent-capture-chance u1 u2 -> n%
This table is the basic chance for u1 to capture an independent
unit of type u2. If the value is -1, then the chance of
capture is given by the capture-chance. Defaults to -1.
Table: scuttle-chance u t -> n%
This table is the chance that a unit whose capture is guaranteed will
destroy itself instead. Scuttling is destructive, so unit changes to
wrecked-type. Occupants of an about-to-be-captured unit will
also attempt to scuttle.
Table: occupant-escape-chance u1 u2 -> n%
This table is the chance that an occupant u1 will escape during the capture of a unit of type u2. Occupants that do not escape are either captured themselves or destroyed, depending on their type and the capturing unit's side.
Table: hp-to-garrison u1 u2 -> n
This table is the number of hp that will be taken from the capturing unit u1 in order to guard a captured u2. If the amount is the unit's full hp, then the unit will vanish and any occupants will be distributed to the captured unit, to open terrain, or will vanish themselves if there is no other option.
Table: countercapture u1 u2 -> n
This table defines the defending unit's reaction to the capture attempt. If 0, then the unit does not react to the capture attempt.
Captures can also affect combat experience, but has different effects on the capturing and captured units.
Table: cxp-per-capture u1 u2 -> cxp
This table is the number of combat experience points gained by u1 for capturing u2.
UnitTypeProperty: cxp-on-capture-effect n
This property gives the change in a unit's cxp due to being captured,
expressed as a multiplier.
Defaults to 100.
Capture of a unit may also yield an extra dividend of knowledge, in the form of information known to the other side.
UnitTypeProperty: see-terrain-if-captured n%
If the world's terrain is not already seen, this property is the chance that the capturing side will get all of the terrain view collected by the former side of the captured unit. This does not apply to any unit views, just terrain.
Table: see-others-if-captured u1 u2 -> n%
This table is the chance that the capturing side will get a view of a unit of type u2 belonging to the other side. The chance applies to each unit of that type when a unit of type u1 is captured.
Detonation is an action and/or behavior that causes damage indiscriminately.
The action specifies the location of the detonation,
which may be in the unit's cell or an adjacent one.
A unit that detonates loses hp, changing to its wrecked-type
if it loses all of its hp.
It also hits every unit within a specified radius.
Detonation may also affect terrain within a specified radius.
ActionType: detonate x y z
This action detonates the actee at the given location x,y,z.
UnitTypeProperty: acp-to-detonate acp
This property is the number of action points used by one detonate action.
Defaults to 0, which disallows detonation.
UnitTypeProperty: hp-per-detonation hp
This property is the number of hp lost in each detonation.
Table: detonation-unit-range u1 u2 -> dist
This table gives the range of effect from detonation of u1. The severity falls off according to the inverse square law extrapolated from the adjacent cell damage. (1/4 severity at range 2, 1/9 at 3, etc.)
Table: detonation-damage-at u1 u2 -> hp
This table is the severity of u1's hit on a unit u2 in the same cell.
Table: detonation-damage-adjacent u1 u2 -> hp
This table is the severity of u1's hit on a unit u2 in an adjacent cell.
Table: detonation-terrain-range u t -> dist
Table: detonation-terrain-damage-chance u t -> n%
Table: terrain-damaged-type t1 t2 -> n
Relative chance that terrain of type t1 damaged by a detonation will change into another type t2.
The following tables and properties can be used for units that cannot detonate deliberately by doing a detonate action.
Table: detonate-on-hit u1 u2 -> n%
This table is the chance that a hit on u1 by a unit of type u2 will cause it to detonate (once). Noncombat reductions in hp, such as attrition, have no effect.
UnitTypeProperty: detonate-on-death n%
This property is the chance that if this type is about to die from a combat hit, it will detonate first.
Table: detonate-on-capture u1 u2 -> n%
This table is the chance that a unit of type u1 will detonate if a capture by a unit of type u2 is about to succeed.
Table: detonate-on-approach-range u1 u2 -> dist
When a unit of type u2 on a non-trusted [?] side appears at a
distance of dist or less, then u1 will detonate. If
-1, then unit will not detonate upon approach. Defaults to
-1.
Table: detonation-accident-chance u t -> n.f%
This table is the chance that the unit will detonate spontaneously. This is checked once/turn, at the beginning of the turn, and also upon each entry to a cell, if moving.
ActionType: alter-terrain x y t
This action changes the type of the cell at x,y to t.
ActionType: add-terrain x y dir t
This action adds a connection or border of type t to the cell at x,y, in direction dir.
ActionType: remove-terrain x y dir t
This action removes a connection or border of type t to the cell at x,y, in direction dir.
Table: acp-to-add-terrain u t -> n
Table: acp-to-remove-terrain u t -> n
For auxiliary terrain types, these tables are the costs to add or
remove. For cell terrain, the costs of removing the old type and adding
the new type are added together. If the value is 0, then that type of
terrain may not be added or removed. As a special exception, cell
terrain may have a cost to remove of 0, so that the sum of add and
remove costs can be as low as 1; in that case, a value of -1 disallows
removal. Both default to 0.
Table: alter-terrain-range u t -> n
This table is the maximum distance at which a unit can alter terrain
t. Defaults to 0, which means that the unit can change
only the terrain in its own cell.
Note that if see-terrain-always is false, then other sides will
not see the terrain change unless they are viewing the altered terrain.
Table: material-to-add-terrain u m -> n
This table is the amount of material necessary to perform an
add-terrain or alter-terrain action.
Table: material-to-remove-terrain u m -> n
This table is the amount of material necessary to perform a
remove-terrain action.
Table: consumption-per-add-terrain t m -> n
This table is the amount of material m necessary for any unit to add terrain of type t.
Table: material-per-remove-terrain t m -> n
This table is the amount of material of type m that becomes available as the result of removing terrain t.